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PREFACE 


This  report  is  one  output  resulting  from  a program  to 
develop  an  analysis  and  evaluation  methodology  f'"*  dealing  with 
questions  regarding  operational  Command  and  Control  (C&C) . As  a 
prelude  to  the  report  it  might  be  well  to  briefly  describe  our 
view  of  C&C  and  of  program  purpose,  and  to  discuss  how  this 
report  relates  to  the  program.  For  more  detailed  discussions  of 
C&C  and  a presentation  of  the  overall  methodology,  the  reader  is 
referred  to  Reference  1 and,  especially.  Reference  2 (see  page 
31). 


C&C  can  be  defined  most  succinctly  by  saying  that  it  is  the 
unautomated,  or  human,  management  element  of  any  system, 
responsible  for  enactment  of  that  system's  role  and  achievement 
of  its  goals.  The  overall  C&C  structure  for  any  one  system  is 
being  described  as  a hierarchical  chain-of-command  which  links 
system-subsystem  definitions,  is  responsible  to  higher  links  in 
the  external  chain-of-command,  and  which  establishes  and  directs 
system  mechanisms  for  the  purposes  of  C&C  information  acquisition 
and  utilization.  Any  one  system,  at  whatever  level  of  definition, 
is  seen  as  being  composed  of  at  least  the  following:  (1)  a C&C 

Functional  Model,  (2)  a system  'plant',  (3)  a system  environment, 
and  (4)  the  aforementioned  information  mechanisms.  It  is  very 
important  to  note  that  what  constitutes  the  system  'plant',  or 
the  controlled  element,  at  one  level  of  system  definition  may 
well  constitute  the  command  element  at  another  level  of  syscem 
definition.  All  of  the  foregoing  can  be  constituted  of  either 
men  or  men  and  machines,  as  appropriate  to  the  problem  under 
consideration. 

The  purpose  of  the  overall  program  is  to  develop  a method- 
ology  which  will  enable  the  Navy  analyst  to  gain  better  status, 
predictive,  and  diagnostic  information  about  operational  C&C 
and,  therefore,  about  the  effectiveness  and  performance  of  manned 
systems.  It  has  previously  been  the  case  that  C&C  has  generally 
not  been  included  as  an  integral  part  of  most  system  design  and 
operations  analysis  programs.  Rather,  if  and  when  analyzed,  it 
has  been  analyzed  as  a subject,  or  system,  in  and  of  itself;  but 
as  can  be  inferred  from  the  above  definition  of  C&C,  this  is  a 
useless  and  often  rounter-productive  exercise.  C&C  has  meaning 
and  purpose  only  as  an  integral  element  of  a particular  system; 
the  purpose  of  the  overall  program  is  to  provide  a methodological 
framework  for  analyzing  C&C  from  this  viewpoint. 

When  C&C  is  viewed  as  the  integral  management  element  of  a 
particular  system,  as  that  part  responsible  for  system  perform- 
ance and  effectiveness,  then  it  can  be  evaluated  only  through 
careful  analysis  of  system  cause  and  effect  variables  which 
constrain  ^nd/or  are  the  responsibility  of  the  C&C  element  - e.g., 
the  "plant"  and  "environment"  variables.  The  implication  here  is 
that  substantive  questions  regarding  a complex  operational  system 
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or  its  command  and  control  element  will  often  require  the 
development  of  a substantial  model  of  that  system  and  its 
components  so  as  to  reflect  the  effects  of  C&C  strategies  and 
tactics  on  the  states  and  activities  of  system  components  and 
the  consequence  effects  on  their  performances  and  on  system 
effectiveness.  The  model  developed  of  the  system,  its  components, 
and  its  operations  must  be  in  a form  which  allows  a compatible 
expression  for  human  and  equipment  components  and,  further, 
allows  the  expression  of  C&C  actions  and  the  consequent  effects 
on  system  behavior. 

The  purpose  of  the  part  of  the  program  presented  in  this 
paper  was  to  develop  a way  of  modeling  systems  for  computer 
analysis  which  would  provide  the  foregoing  capabilities  of 
expression,  analysis  and  evaluation.  The  approach  taken  was  to 
review  the  techniques  available  for  computer  model  development, 
select  the  most  promising  technique,  to  test  out  its  capabilities 
through  the  modeling  of  a particular  system  with  which  we  had  had 
considerable  experience,  and  to  begin  transforming  this  experi- 
ence into  a method  for  command  and  control  analysis.  This  paper 
presents  the  work  completed  under  this  part  of  the  program  and, 
as  a final  comment,  it  appears  that  the  simulation  languages 
present  capabilities  for  manned  systems  modeling  which  have  not 
yet  been  fully  exploited.  Considerable  potential  remains 
untapped. 
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X.  INTRODUCTION 


One  approach  to  the  evaluation  of  manned  systems  and  their 
command  and  control  elements  is  direct  empirical  observation. 
However,  direct,  measurement,  and  especially  the  study  of  system 
variables  by  systematically  altering  conditions  within  a manned 
system,  are  of tern  impractical.  A model  of  the  system  which 
allows  variation  and  measurement  may  therefore  be  a cost 
effective  alternative,  and  a computer  model  for  such  purposes 
is  sought  in  this  paper.  Such  a model  must  include  computer 
representations  of  both  human  and  machine  components,  so  that 
subsystem  and  total  system  performance  can  be  measured  in  terms 
of  computer  parameters. 

The  primary  purpose  of  this  report  was  to  develop  a method 
of  computer  modeling  for  command  and  control  analysis.  The 
method  is  called  the  Command  and  Control  Analysis  Model.  A 
computer  model  was  programmed  at  two  levels  of  complexity,  but 
since  the  emphasis  was  on  the  development  and  exposition  of 
methods,  as  simple  a model  as  possible  was  developed  for  test 
and  evaluation.  Complete  detailed  examples  were  not  actually 
developed  and  tested,  but  sufficient  direct  programming  experi- 
ence was  accumulated  so  as  to  provide  a basis  for  the 
establishment  of  general  procedures  and  some  evidence  of  the 
workability  of  the  approach. 

The  General  Purpose  System  Simulator  (GPS3)  language  was  a 
convenient  choice  for  this  study  but  other  computer  simulation 
languages  are  available  to  serve  similar  purposes.  The  GPSS 
language  was  used  to  construct  an  example  simulation  based  on  the 
Carrier  Air  Traffic  Control  Centar  (CATCC) . Both  human  and 
machine  components  are  included,  and  the  role  of  computer  models 
in  Command  and  Control  analyses  is  discussed.  Guidelines  for 
the  development  o ! computer  models  are  generated  to  guide  future 
applications  of  this  technique.  An  interesting  side  issue  is 
that  the  computer  simulation  languages  have  such  rich  descriptive 
capabilities  that  for  human  task  performance  deficiencies  in 
standard  task  analyses  techniques  are  made  apparent. 
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II.  BACKGROUND 


A BRIEF  INTRODUCTION  TO  GPS3 

The  General-Purpose  System  Simulator  (GPSS)  is  a computer 
language  for  modeling  those  systems  which  involve  flows  of 
transactions  and  events  over  time.  The  GPSS  language  also 
permits  the  collection  of  statistical  records  about  system 
quantities.  Some  common  examples  of  systems  which  can  be 
simulated  with  GPSS  are  traffic  flow  (e.g.,  people,  automobile 
or  aircraft  movements),  factory  assembly  lines,  distribution 
systems,  and  many  aspects  of  man-machine  systems.  There  are 
other  simulation  languages  for  computer  modeling  (e.g.,  SIMSCRIPT, 
SIMPAC,  CSL,  ESP,  SIMON,  GSP,  MONTECODE,  SIMULA,  DYNAMO,  and 
OPS),  bat  GPSS  will  be  presented  here  so  as  to  allow  concrete 
examples 

GPSS  (Refs.  3 and  4)  is  a block-diagi am-oriented  language. 
When  a system  block  diagram  is  prepared  at  a sufficiently 
molecular  level  using  a GPSS-specif ic  set  of  blocks,  the  computer 
program  can  be  derived  directly  from  the  block  diagram.  Take 
for  example  the  block  diagram  of  a simple  queue  forming  at  a 
theatre  ticket  window  as  presented  in  Figure  1.  In  sequence, 
the  block  diagram  indicates  that,  the  computer  model  should 
(1)  GENERATE  transactions  (people)  and  cause  them  to  be  introduced 
at  intervals  according  to  a specified  distribution,  (2)  form  a 
QUEUE,  or  waiting  line,  for  people  waiting  their  turn  and  keep 
statistical  records  on  the  length  Ci  the  line  and  waiting  time, 

(3)  SEIZE  a facility  (the  ticket  vendor)  when  an  individual  gets 
to  the  front  of  the  line  and  the  ticket  vendor  is  not  busy, 

(4)  DEPART  the  queue,  (5)  ADVANCE  the  clock  according  to  a 
specified  distribution  to  account  for  the  time  needed  for  the 
ticket  to  be  given  and  money  exchanged,  (6)  RELEASE  the  facility 
or  the  next  person  in  line,  (7)  TABULATE  statistics  (update 
frequency  distributions)  of  system  quantities  for  printout  at 
the  end  of  the  computer  run,  and  (8)  TERMINATE  the  transaction 
(individual)  from  the  system.  This  block  diagram  can  be  trans- 
lated into  a computer  program  along  with  specific  system 
quantities.  The  computer  model  can  then  be  exercised  until  a 
specified  number  of  transactions  are  completed;  subsequently 
the  run  would  stop  with  a printout  of  requested  statistics. 

GPSS  involves  a number  of  entities  which  are  include3,  in  a 
system  model  simply  by  referencing  them  by  number  (as  there  may 
be  many  of  each) . First,  transactions  are  entities  which  flow 
through  the  system  block  diagram.  Transactions  may  be  thought 
cf  as  people,  automobiles,  airplanes,  mail,  etc.,  as  one  wishes. 
Each  transaction  carries  with  it  twelve  or  more  numbered 
parameters.  Values  associated  with  each  parameter  can  be  used 
to  characterize  the  transaction.  Facilities  are  entities  which 
simulate  the  processing  of  transactions,  with  as  few  as  one 
transaction  at  a time  being  processed.  Storages  may  process  (or 
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Figure  1.  An  Example  GPSS  Block  Diagram  (of 
Queue  at  a Theatre  Ticket  Window. 


store)  a number  of  transactions  at  a time,  but  a capacity  for 
storage  must  be  specified.  Queues , as  already  indicated,  are 
used  to  cause  the  GPSS  system  to  maintain  statistics  on  lines 
which  form,  Savevalues  are  numbered  storage  areas  where  special 
data  may  be  kept  until  the  end  of  a run.  Standard  Numerical 
Attributes  (SNA)  are  system  quantities  which  are  automatically 
remembered.  These  and  other  entities  are  available  to  the  GPSS 
programmer  to  create  a computer  model. 

The  GPSS  language  and  the  concepts  included  will  be  used  in 
this  report  to  develop  a computer  model  of  a specific  man-machine 
system.  This  specific  model  has  been  constructed  so  as  to  serve 
as  a vehicle  for  describing  methods  for  developing  models  of 
other  systems  for  command  and  control  analysis  purposes.  The 
generic  name  for  these  types  of  models  is  the  Command  and  Control 
Analysis  Model. 

The  specific  system  to  be  modeled  in  this  report  is  the 
Carrier  Air  Traffic  Control  Center.  It  controls  the  recovery  of 
aircraft  on  an  aircraft  carrier  and  possesses  a substantial 
command  and  control  element.  The  essential  characteristics  of 
this  system  are  outlined  in  the  following  section. 

A BRIEF  INTRODUCTION  TO  THE  CARRIER  AIR  TRAFFIC  CONTROL  CENTER 

The  carrier  air  traffic  control  system  (Ref.  1)  consists  of 
several  agencies,  each  with  specific  control  functions  and 
responsibilities  for  coordinating  with  the  other  agencies.  As 
one  of  these  agencies,  the  Carrier  Air  Traffic  Control  Center 
(CATCC)  has  primary  responsibility  for  aircraft  requiring 
positive  center  control  (e.g.,  under  instrument  flight  conditions) 
within  a one  hundred  mile  radius  of  the  ship  for  which  that  ship 
is  either  the  destination  or  point  of  departure.  For  aircraft 
operating  under  other  control  conditions,  CATCC  interacts  with 
other  agencies  for  control  purposes  and/or  monitors  to  ensure 
traffic  safety. 

One  of  the  more  difficult  CATCC  activities,  and  the  one 
which  requires  the  most  complete  and  fullest  utilization  of  CCA 
capabilities,  is  a Mode  III  recovery  of  a scheduled  flight  of 
aircraft.  The  number  of  aircraft  per  scheduled  recovery  commonly 
ranges  from  7 to  18.  CATCC  recovery  of  a flight  of  aircraft  is 
considered  to  be  one  of  the  more  stressful  air  traffic  control 
activities.  The  activity  is  stressful  due  to  the  task  require- 
ments for  control  within  quite  close  position  and  time  tolerances 
and  for  management  of  what  can  become  a complex  traffic  pattern 
with  many  variables  in  operation.  The  level  of  stress  is 
increased  by  the  awareness  of  the  extreme  costs  in  terms  of  lives 
and  aircraft  that  can  be  incurred  by  failing  to  meet  task 
requirements . 

The  CCA  control  positions  usually  manned  for  these  recovery 
operations  are  Marshal  and  Subteams  A and  B,  with  each  subteam 
consisting  of  one  Approach  and  one  Final  Controller.  Other 
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personnel  directly  involved  in  support  or  supervisory  roles 
include  the  Carrier  Controlled  Apprr  sh  Officer  (CCAO) , the 
Supervisor,  and  Boardkeepers  for  tl.j  marshal  and  final  status 
boards. 

During  recovery  operations,  the  aircraft  are  initially 
under  Marshal  control.  The  Marshaller  organizes  aircraft  within 
the  marshalling  configuration  and  ensures  their  individual 
entry  into  the  approach  pattern  at  the  appropriate  time. 

Aircraft  handoffs  from  Marshal  to  Approach  usually  alternate 
between  Subteams  A and  B,  with  subsequent  handoffs  from  Approach 
to  Final.  The  flow  for  CCA  control  and  integration  functions 
during  scheduled  Mode  III  recoveries  is  presented  in  Figure  2. 
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III.  COMMAND  AND  CONTROL  SIMULATION  WITH  GPSS 


Since  GPSS  produces  models  in  which  transactions  flow 
through  a system,  the  starting  point  in  producing  a simulation 
is  the  identification  of  the  paths  along  which  transactions 
flow,  and,  of  course  the  different  kinds  of  transactions.  For  a 
CATCC  model,  the  following  transactions  and  paths  are  appropriate 
as  shown  in  Figure  3:  (1)  the  flow  of  aircraft  from  the  Marshal 

point  down  to  the  deck  of  the  carrier,  (2)  data  about  the 
aircraft,  flowing  to  the  CATCC,  (3)  control  instructions,  flowing 
from  CATCC  to  the  various  aircraft,  (4)  transformations  of  (2)  to 
produce  (3)  flowing  internally  within  CATCC,  and  (4)  command 
information,  flowing  from  external  sources  to  CATCC. 

When  block  diagrams  are  generated  for  each  flow,  programs 
generated  and  executed  on  a digital  computer,  all  types  of  GPSS 
transactions  flow  "simultaneously"  simulating  an  information- 
processing management  system  in  which  transformations  and 
interactions  occur  in  the  same  event/time  relationships  as  the 
CATCC.  The  GPSS  Software  permits  record  keeping  and  the 
calculation  of  measures  of  effectiveness  as  the  analyst  desires. 

For  our  purpose,  which  was  the  development  and  exposition 
of  methods  for  developing  computerized  command  and  control 
analysis  models,  two  versions  of  a GPSS  CATCC  model  were  produced. 
The  first  version  was  a very  simple,  and  therefore  unrealistic, 
model  of  CATCC  while  the  second  version  was  more  complex  and 
incorporated  modules  of  interest  in  the  analysis  of  manned 
systems.  The  development  of  two  versions  was  u part  of  an 
iterative  methods  development,  test,  and  evaluation  process. 

Both  versions  are  discussed  in  this  chapter . Subsequent  chapters 
will  use  the  background  provided  by  this  chapter  for  exploring 
model  development  guidelines  and  uses. 

A SIMPLE  GPSS  SIMULATION 

A simple  GPSS  simulation  for  the  control  of  a flow  of  air- 
craft is  presented  in  Figure  4 in  block  diagram  form  (A  complete 
listing  of  the  GPSS  program  is  presented  in  Appendix  A) . This 
model  is  oversimplified  in  at  least  two  respects:  (1)  information 

and  control  related  to  the  aircraft  are  updated  at  only  one  mile 
intervals,  and  (2)  the  controller  is  a simple  unit  which  only 
tests  spacing  and  sends  aircraft  bad:  into  line  whenever  the 
spacing  is  too  close.  This  simple  model  will  be  used  to  develop 
methods  and  illustrate  potential  application  to  a system  such  as 
CATCC;  additional  modules  for  model  sophistication  will  be 
discussed  later. 

The  following  comments  apply  to  the  block  diagram  of  Figure 
4: 
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AIRCRAFT 


Figure  3. 


Information/Event  Flow  in  a Simple 
GPSS  Model  of  CATCC. 
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Figure  4.  A Simple  GPSS  Simulation 
(General  Block  Diagram) 


Parameters . Each  transaction  (aircraft)  in  the  aircraft 
flow  has  associated  with  it  a number  of  parameters  as  shown  in 
Table  1.  The  value  of  each  parameter  characterizes  each  aircraft 
and  becomes  the  basis  for  identifying  and  controlling  information 
flowing  in  the  system. 

Generation  of  flights.  Flights  are  generated  at  specified 
intervals  (a  constant  interval,  or  a mean  value  with  a specified 
distribution) . As  each  flight  is  generated,  the  number  of 
aircraft  in  each  flight  is  determined  as  well  as  the  parameters 
for  each  aircraft?  each  of  these  may  be  constants,  computed 
values,  or  selected  from  a random  generator  with  specified 
characteristics.  Flight  size  and  fuel  remaining  are  determined 
through  random  distribution  FN1  and  FN3  (i.e.,  function  one  and 
function  three) . 

Marshal  point.  Each  arriving  aircraft  is  assigned  an 
estimated  time  to  begin  its  approach  to  the  carrier?  each  is 
separated  by  one  minute.  Subsequently,  the  time  for  each  aircraft 
to  begin  approach  is  compared  to  the  GPSS  clock  to  determine  when 
the  aircraft  can  continue  again. 

Aircraft  flow.  As  each  aircraft  flows  through  the  system 
("down  the  approach")  the  following  occur:  (1)  glideslope, 

azimuth,  and  airspeed  errors  are  introduced  through  specified 
random  distributions  identified  in  GPSS  as  functions  (FNl , FN2, 
FN3) , (2)  each  aircraft  transaction  is  split  into  two  duplicate 

transactions,  one  of  which  continues  as  an  aircraft  in  the 
aircraft  flow,  and  the  other  is  sent  as  data  along  the  data  flow 
path,  (3)  the  clock  is  advanced  and  fuel  is  decremented  to 
reflect  traveling  one  mile,  and  (4)  if  control  is  dictated,  the 
aircraft  is  held  and  fuel  decremented  to  simulate  placing  the 
aircraft  at  a new  position  in  the  approach  line  up.  These  events 
occur  iteratively  until  each  aircraft  transverses  the  20-m.ile 
path  (20  times  through  the  aircraft  flow  loop) . 

Information  processing.  The  information  processor  in  this 
simple  example  bears  little  resemblance  to  CATCC  operations. 

Only  one  controller,  with  few  human  characteristics,  is  included? 
this  controller  tests  the  spacing  between  aircraft,  and  when  an 
aircraft  is  following  too  closely  it  is  sent  to  a pre-planned 
opening  in  the  approach  line  up.  As  information  in  the  form  of 
position  reports  arrive  at  the  controller,  the  number  of  items 
of  information  unprocessed  is  counted  and  additional  information 
discarded  to  keep  the  queue  sufficiently  short  so  that  exception- 
ally old  information  is  not  processed.  When  the  controller  is 
free,  the  time  of  arrival  of  each  aircraft  at  a specific  mile 
checkpoint  is  compared  with  the  time  the  last  aircraft  arrived  at 
the  same  checkpoint.  If  the  time  difference  was  less  than  30 
seconds,  a control  action  is  originated  (split  from  the  data 
transaction) ? otherwise,  the  data  transaction  would  be  terminated 
(discarded  from  the  information  processing  subsystem) . A control 
action  consisted  of  computing  the  time  for  the  aircraft  to  be 
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TABLE  1.  PARAMETERS  ASSOCIATED  WITH  EACH 
AIRCRAFT  TRANSACTION 


PARAMETER 

CONTENTS 

FI 

Flight  Number 

P2 

Flight  Size 

P 3 

Type  Aircraft 

P4 

Serial  Number 

P5 

Seconds  of  Fuel  Remaining 

P6 

Clock  Time  Storage 

P7 

Airspeed  (seconds  per  mile) 

P8 

Heading  Error  (degrees) 

P9 

Glideslope  Error  (feet) 

P10 

Checkpoint  (miles  to  go) 

Pll 

Holding  Time  (seconds  to  hold  A/C) 

P12 

Clock  Time  Fit  Arrives  at  Marshal 

held,  and  allowing  this  information  to  be  communicated  to  the 
aircraft-flow  simulation. 

Measures  of  effectiveness.  As  the  system  simulation 
proceeds , system  quantities  are  automatically  recorded.  At 
specified  points  in  the  various  flows,  statistical  tabulations 
are  updated  for  summary  printout  at  the  end  of  the  computer  run. 
Statistical  tabulations  may  include  airspeed,  heading  and  glide- 
slope  errors,  fuel  remaining  after  recovery,  controller  processing 
time,  aircraft  spacing,  flight  recovery  time,  and  others.  The 
computer  run  terminates  after  a specified  number  of  aircraft  have 
landed  on  the  carrier  deck. 

Tables  2 and  3 present  example  statistical  output  for 
airspeed  and  spacing,  respectively.  The  GPSS  programmer  defines 
intervals  for  each  tabulated  value,  and  then  frequency  counts  are 
accumulated  during  the  GPSS  run.  In  each  table,  che  following 
information  is  presented:  the  interval  (in  terms  of  the  value 

at  the  upper  limit  of  each  interval),  the  observed  frequency 
count  in  each  interval,  the  frequency  information  in  terms  of 
the  percent  of  the  total  number  of  entries  in  the  table, 
cumulative  percentages  and  100%  minus  the  cumulative  percentage, 
the  multiple  of  the  mean,  and  the  deviation  from  the  mean. 
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The  mean,  standard  deviation,  sum  of  arguments,  and  the  total 
number  of  entries  in  the  table  are  also  presented  as  summary 
information. 


ADDITIONAL  MODULES  FOR  CATCC  SIMULATION 


While  the  above  model  contains  some  characteristics  desired 
in  a CATCC  model,  it  definitely  lacks  many  others.  Among  these 
are  the  following,  which  may  be  considered  as  additional  modules 
to  bo  added  or  substituted  in  the  previous  simple  model  to 
achieve  a more  desirable  model  form  (Appendix  B contains  a 
complete  listing  of  the  resulting  expanded  GPSS  program) : 

MULTIPLE  CONTROLLERS  If  a command  and  control  analysis  is  to 
properly  consider  the  man-machine  problems  encountered  in  CATCC, 
the  individual  workers  and  their  communication  channel.*5  must  be 
identified.  For  example,  the  personnel  "facilities''  should 
minimally  include  the  Marshal  Controller,  two  Approach  Control- 
lers, two  Final  Controller,  a status  board  keeper,  and  personnel 
from  related  command  agencies. 


Consider  the  following  GPSS  example  (from  Appendix  B) : 


SEIZE  11 
ADVANCE  100 
SEIZE  2 
ADVANCE  150 

ASSIGN  6, V6 


Seize  a Communication  channel 

Account  for  time  for  A/C  to  report  in 

Seize  the  Marshal  Controller  "facility" 

Account  for  time  to  assign  an  approach 
time 

Assign  an  approach  time  to  parameter  6 


Two  facilities  are  identified:  a communication  channel  and  the 

Marshal  Controller.  When  an  aircraft  reports  in  a communication 
channel  (facility  #11)  must  first  be  available  and  time  is  taken 
for  communicating  the  message.  When  the  Marshal  Controller 
(facility  #2)  is  free  and  after  sufficient  time  to  determine  the 
desired  appraoch  time,  the  approach  time  is  assigned  to  the 
aircraft  (information  to  be  stored  in  parameter  6). 


DISPLAYS  To  permit  the  simulation  of  individuals'  tasks, 
display  information  must  be  provided  in  the  model  in  a form 
required  by  each  task.  For  example,  information  derived  from  a 
radar  can  be  stored  in  specific  computer  storage  areas  (SAVEVALUES) 
which  the  mod  1 can  access  as  needed.  This  permits  radar  informa- 
tion to  be  subsequently  degraded  or  missing  as  appropriate  to 
operational  radar.  Also,  status  boards  can  be  similarly 
modeled,  permitting  realistic  update  intervals  by  the  simulated 
status  board  keeper. 


A method  for  storing  display  information  for  access  as 
needed  is  to  arrange  a series  of  Savevalue  locations  to  corres- 
pond to  a matrix  of  aircraft  numbers  and  all  parameters  for  each 
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aircraft.  When  a data  transaction  is  received  GPSS  variables 
are  used  to  compute  the  proper  place  in  the  matrix  for  each 
associated  parameter  {see  Radar/Display  Information  Updating 
in  the  program  listing  in  Appendix  B) . When  information  is 
needed  from  a display  for  a human  operator  task,  a similar 
computation  can  be  performed  to  retrieve  the  latest  information 
from  the  matrix.  One  can  also  insert  additional  display 
properties,  such  as  loss  of  information  during  a specific  range 
of  distance  by  testing  the  distance  before  accessing  the  matrix 
and  use  the  stored  information  only  if  outside  the  zone  of  radar 
loss . 

CONTROL  The  control  provided  in  the  simple  model  does  not 
reflect  the  full  repertoire  potentially  available  in  the  CATCC. 

A number  of  different  maneuvers  are  used  operationally  to  manage 
traffic  flow,  conflict,  and  emergency  situations  and  could  be 
added  to  the  model. 

In  the  current  simulations,  x-y  position  of  each  aircraft 
is  not  computed,  only  the  position  along  the  approach  path. 
Control  is  exercised  by  halting  motion  along  the  path  for  a 
specified  time,  changing  speed,  or  moving  the  aircraft  back  up 
the  approach  path  (e.g.,  to  the  Marshal  point).  Consequently, 
within  this  simulation,  the  control  actions  can  include:  (1) 

delay  aircraft  advance  by  using  an  ADVANCE  block  and  decrementing 
fuel  by  modifying  parameter  5 with  an  ASSIGN  block,  (2)  change 
speed  by  modifying  the  value  stored  in  parameter  7,  using  an 
ASSIGN  block  or  (3)  send  the  aircraft  back  to  a specific  place 
in  the  flight  path  where  a space  in  the  approach  sequence  is 
available  (using  an  ASSIGN  block  to  change  parameter  10  for 
for  distance  to  go  and  parameter  5 for  fuel  remaining,  and  an 
ADVANCE  block  to  account  for  the  time  required) . 

TASKS  Each  task  pertinent  to  information  processing  should  be 
included  in  a CATCC  simulation  if  it  were  to  be  used  for  detailed 
prediction  and  diagnosis  analyses.  Many  tasks  are  initiated  by 
specific  stimuli;  for  example,  a position  report  may  initiate  a 
task  by  a controller,  which  when  completed  may  initiate  another 
task,  and  so  on.  Other  tasks  may  be  rather  continuous  such  as 
monitoring  aircraft  spacing  on  a radar  screen,  or  others  may  be 
initiated  as  time  permits;  however,  such  tasks  may  be  timeshared 
with  other  tasks,  so  that  a task  priority  structure  is  clearly 
needed. 

An  example  of  a continuous  activity  is  that  of  monitoring 
the  radar  screen  for  adequate  spacing  between  aircraft.  The  rate 
of  such  activity  can  be  controlled  using  a GENERATE  block  to 
create  transactions  which  are  used  to  cause  radar  information  to 
be  accessed,  tested,  and  appropriate  actions  to  be  taken.  For 
example: 
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GENERATE  10 
SEIZE  4 

TEST  G V26,  K13,  CLOSE 

* 

ADVANCE  2 
RELEASE  4 
TERMINATE 


Is. 


In  this  case  a transaction  is  created  every  10  clock  units, 
which  causes  the  distance  between  aircraft  to  be  confuted  (using 
variable  26  for  computation)  and  if  the  distance  is  less  than  13 
distance  units  then  the  appropriate  control  actions  will  be  taken 
(at  address  CLOSE) . Other  tests  may  be  initiated  by  the  trans- 
action if  inserted  before  the  TERMINATE  block. 

Note  the  use  of  SEIZE,  ADVANCE  and  RELEASE  blocks  in  the 
above  example  to  ensure  that  facility  4 (Approach  Controller  A) 
is  available,  account  for  his  time  occupied,  and  free  him  when 
completed.  This  member  of  the  team  may  of  course  have  other 
demands  on  his  time  simultaneously.  GPSS  and  similar  languages 
allow  for  a priority  structure  so  that  if  more  than  one  trans- 
action attempts  to  seize  a facility  at  the  same  time  the  facility 
can  be  devoted  first  to  the  more  important  one.  Two  cases  can 
be  directly  implemented  using  GPSS:  (1)  when  a given  transaction 

must  be  serviced  immediately,  use  of  a PREEMPT  block  will  obtain 
immediate  use  of  a facility  and  permit  the  facility  to  then 
continue  later  by  reconvening  service  of  any  previous  transaction 
and  (2)  transactions  may  be  assigned  a priority  which  modifies 
the  normal  first-come  first-served  rule.  Other  priority 
structures  may  be  implemented;  for  example,  task  A may  be 
divided  into  segments  (SEIZE- RETURN , SEIZE- RETURN, . . . ) causing 
the  facility  seized  to  be  entirely  devoted  to  a transaction  in 
segments,  but  free  for  other  activities  at  predetermined 
intervals . 


(■Ifys? 


IV.  GUIDELINES  FOR  COMPUTER  MODEL  DEVELOPMENT 


The  model  explored  in  Chapter  III  of  this  paper  used  the 
CATCC  as  an  example  relevant  to  manned  systems  with  a substantial 
command  and  control  element.  The  specific  procedures  and 
problems  encountered  with  that  example  are  generalized  as 
guidelines  in  this  chapter  so  that  the  analyst  may  attempt  to 
adapt  these  to  his  specific  needs  with  other  similar  systems. 

SYSTEM  INFORMATION  NEEDED 

As  the  computer  model  is  to  be  an  analog  of  the  operating 
real  system,  a great  deal  of  information  is  needed  about  each 
facet  of  the  system  which  is  to  be  reflected  in  the  model.  Among 
the  areas  of  system  information  needed  are  the  following: 

1.  A description  of  the  controlled  element,  the  variables 
which  specify  the  state  of  the  controlled  element,  and  variables 
which  are  used  for  control. 

2.  A specification  of  each  channel  of  communication 
(various  forms  of  electronic,  visual,  and  auditory  communication 
devices),  and  the  capacities  and  manner  of  use  fo.-  each  channel. 

3.  Those  machine  elements  of  the  system  which  share  the 
information  processing  and  control  tasks  with  the  human  elements 
must  be  identified  and  described.  They  must  be  characterized 
(e.g,,  failure  characteristics)  so  that  they  can  be  realistically 
represented  in  the  computer  model. 

4.  The  information  to  be  visually  displayed  within  the 
system  must  be  listed,  along  with  display  characteristics  which 
may  be  of  interest  for  model  use  such  as  rate  of  updating, 
method  of  accessing  and  display  degradations  (e.g.,  errors  c .d 
missing  information) . 

5.  Incidents  where  human  task  requirements  may  occur 
simultaneously  — creating  a need  for  human  time-sharing  — must 
be  identified.  Methods  for  choosing  between  competing  tasks, 

or  methods  for  time-sharing  tasks,  must  be  defined  in  a manner 
permitting  computer  description. 

6.  The  people  in  the  system  must  also  be  modeled  in  a 
manner  permitting  the  effect  of  human  characteristics  on  human 
performance  to  be  included  in  the  computer  model. 

7.  Scenarios  are  needed  which  describe  the  conditions  and 
load  under  which  the  system  will  typically  operate,  the  computer 
model  must  validly  perform  for  each  required  scenario. 
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AMOUNT  OF  MODEL  DETAIL  AND  COMPLEXITY 


During  computer  model  development  the  system  programmer  will 
face  many  decisions  about  model  detail  and  complexity.  Suffi- 
cient model  detail  is  necessary  for  (1)  proper  uodoi  operation 
and  output,  (2)  proper  information  processing  within  the  model, 

(3)  correct  man-man  and  man-machine  interface,  (4)  valid  human 
and  equipment  performance,  and  (5)  an  adequate  experimental 
design  including  all  independent  and  dependent  variables.  (And 
what  constitutes  an  "adequate"  experimental  design  will  vary  as 
a function  of  whether  the  question  being  asked  is  one  regarding 
system  status,  prediction,  or  diagnosis.  This  issue  regarding 
model  detail  and  complexity  will  be  discussed  again  later.) 

The  programmer  must  consider  all  five  of  these  needs 
during  model  construction.  For  example,  a given  communication 
may  be  of  little  importance  for  the  scenario  and  therefore 
require  only  that  the  amount  of  personnel  time  consumed  be 
accounted  for.  On  the  other  hand,  if  the  communications  are 
relevant  to  scenario  evolution  then  each  item  of  information 
must  be  appropriately  processed  and  stored. 

Often  computer  programming  for  model  development  is  turned 
over  to  a software  specialist  without  adequate  information  on  the 
foregoing.  It  should  be  clear  that  this  could  be  disastrous,  for 
the  programmer  must  then  make  (often  inadvertently  or  by  default) 
many  critical  decisions  about  model  details  in  order  to  develop 
a program  which  will  answer  the  analysts  questions.  In  the 
process  of  doing  this  the  programmer  must  often  generate 
considerable  detail  related  to  human  perfonnance  models.  The 
model  developers,  i.e.,  the  programmers,  must  possess  both 
command  and  control  and  programming  expertise  and,  further,  be 
given  all  the  necessary  and  sufficient  information  about  the 
system,  its  components,  and  its  operations. 

PROCEDURES 

The  steps  listed  below  were  used  in  developing  a GPSS  Model 
of  CATCC  and  are  offered  as  a general  framework  for  the  develop- 
ment of  other  models. 

1.  System  Analysis.  A description  of  the  approaching 
aircraft  the  CATCC  system,  personnel  tasks,  system  procedures, 
and  measures  of  effectiveness  was  formulated.  Scenarios  were 
formed  to  specify  the  precise  conditions  under  which  the  model 
would  be  used.  Development  of  a scenario  independent  model  was 
also  attempted;  however,  it  was  found  that  descriptions  of  CATCC 
system  operation  were  frequently  a function  of  specific  events 
occurring  singly  or  in  a specific  sequence  and  under  specific 
conditions.  Consequently,  the  descriptions  and  therefore  the 
model,  derived  for  one  scenario  might  not  be  valid  for  some 
events  occurring  at  other  times,  in  other  sequences,  or  in 
unusual  combinations.  It  became  clear  that  models  for  command 
and  control  analysis  are  very  scenario  dependent  and  that  the 
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selection  of  a representative  set  of  scenarios  for  system 
description  and,  consequently,  model  development  is  critical. 

2.  Model  Framework.  A model  framework  was  formed,  based 
on  the  system  analyses,  including  the  following  components: 

(1)  the  flow  of  approaching  aircraft  which  provides  information 
to  CATCC  and  which  responds  to  CATCC  control,  (2)  displays, 
which  are  manually  or  automatically  updated,  (3)  the  man-machine 
system,  including  chains  of  events  which  are  initiated  by 
external  stimuli,  and  events  which  are  initiated  internally, 

(4)  measurement,  and  (5)  external  command  inputs. 

3.  Task  and  Communication  Analysxs.  The  tasks  were 
described  using  several  formats,  including  a task  analyses, 
operational  sequence  diagrams  (OSD),  and  decision  tree  analyses. 
The  analyses  defined  the  sequence  of  occurrence  for  initiating 
stimuli  (communications,  or  display  of  triggering  information) 
and  corresponding  actions.  Examples  are  presented  in  Figures  5 - 
7.  From  these  data  GPSS  flows  were  defined,  with  each  flow 
initiated  by  the  proper  event  or  information.  Other  GPSS  flows 
which  resulted  are  those  which  are  initiated  within  CATCC,  or 
which  are  continuously  performed  (as  time  and  events  permit) . 

The  OSDs  were  constructed  for  selected  task  operations  where  the 
GPSS  block  diagram  could  result  from  a direct  mapping  from  the 
OSD.  Decision  analyses  were  used  to  clarify  the  choice  between 
alternatives,  especially  in  the  case  of  emergency  events.  The 
analyses  were  subsequently  placed  on  a tine  line  by  listing 
tasks  and,  for  a given  scenario,  assigninj  a nominal  time  to  each 
task . 


4.  Scenarios  and  Experimental  D^o-jr..  Scenarios  describing 
conditions  under  which  the  computer  model  was  to  be  tested  provided 
such  information  as  the  number  of  aircraft  and  mixes  thereof.  Since 
a number  of  random  variables  and  unpredictable  combinations  of 
events  will  occur  while  exercising  the  computer  model,  experi- 
ments must  be  conducted  with  sufficient  trials  to  achieve  stable 
measurements  of  comparisons  between  alternative  system  configura- 
tions or  inputs.  Of  course,  the  conditions  under  which  the 
computer  model  will  be  used  is  valuable  information  for  model 
development  to  ensure  that  desired  experimental  comparisons  and 
measurements  are  designed  into  the  model. 


5.  Programming  and  checkout.  A computer  program  can  be 
prepared  based  on  the  foregoing  information.  Normally,  the 
programmer  interacts  between  requirements,  the  program,  and  the 
results  of  trial  program  executions  until  he  obtains  what  seems 
to  be  needed.  The  checkout  of  the  program  evolves  in  three 
stages:  (1)  correcting  syntax,  (2)  getting  the  program  to  run, 

and  (3)  getting  the  program  to  run  correctly. 


6.  Program  verification.  The  last  stage  of  program 
checkout,  that  of  getting  the  program  to  run  correctly,  is,  of 
course,  the  most  critical  stage.  The  programmer  should  personal- 
ly possess  both  operational  and  system  knowledge  since  it  is 
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A/C  CHECK-IN  - MONITOR  MARSHAL  PATTERN  - PUSH  TIME  - HANDOFF  TO  APPROACH 
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Figure  6.  Example  Task  Analysis. 


BOLTER/WAVEOFF 


ALTERNATE  OPERATOR  OPTIONS  AND  INFORMATION  FLOW 


Situation:  LSO  signals  waveoff  to  aircraft  at  % mile  from  ramp 

because  of  fouled  deck.  CCA,  AirOps,  PreFly  and 
Bridge  receives  knowledge  of  same  via  monitoring 
activities . 

ACTIVITIES INFORMATION  FLOW 

1.  Bingo  A/C  CCA  Supr.  reviews  status  board  data  and 

determines  best  solution  is  bingo. 

CCA  Supr.  coordinates  with  AirOps  for 
concurrence. 

CCA  Supr.  instructs  Approach  Control  to 
relay  bingo  information  to  pilot. 

Approach  Controller  transmits  bingo  instruc- 
tions to  pilot  and  receives  acknowledgement. 

Status  board  keepers  update  status  boards.  | 


f 

t 
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2.  Bring  bolter  CCA  Supr.  reviews  status  board,  notes  A/C 

A/C  around  for  fuel  state  and  instructs  a new  insertion 

new  approach  ASAP  ASAP. 

Talker  informs  AirOps,  PriFly,  and  Bridge. 

App.  Control  coordinates  with  CCA  Supr., 

Marshal  Control  and  other  Approach  Control- 
ler to  create  space  for  bolter  A/C. 

App.  Controller  and  Marshal  Control  Transmit 
speed,  flight  path  changes,  etc.,  as 
needed  to  affected  A/C  to  accommodate 
bolter  space  creation. 

Pilots  acknowledge  instructions. 

App.  Controller  transmits  insertion  instruc- 
tions to  bolter  A/C  and  handcff  to  Final 
Controller  when  appropriate. 

Bolter  A/C  checks  in  with  Final  Control/LSO 
and  completes  landing. 

Status  board  keepers  maintain  updated 
status  boards. 


3.  Reinsert  bolter 
A/C  at  the  end 
of  the  line  after 
refueling 


CCA  Supr.  reviews  radars,  status  boards  for 
recovery  sequence  details  and  determines 
bolter  A/C  will  refuel  and  make  new  ap- 
proach from  marsnal. 

Talker  relays  CCA  Supr.  action  to  AirOps, 
PriFly  and  Bridge. 

CCA  Supr.  instructs  Approach  Controller  to 
relay  instructions  to  bolter  pilot. 

App.  Control  instructs  bolter  pilot  to  con- 
tact Departure  Control  for  refuel  instruc- 
tions . 

Bolter  pilot  acknowledges. 

After  refuel,  bolter  pilot  re-enters  marshal 
area  and  checks  in  with  Marshal  Control. 
Status  board  keepers  maintain  board  update. 


Figure  7.  Example  Decision  Tree  Analysis. 
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unlikely  that  he  will  be  able  to  derive  what  he  needs  from 
other  people  in  the  form  needed.  However,  the  task  will  be 
expedited  if  specific  check  cases  are  constructed  for  which 
desired  results  are  fully  known.  Also,  highly  detailed  and 
redundant  measurement  printouts  will  help  identify  unanticipated 
problems.  Aside  from  these  few  suggestions,  it  can  only  be  said 
that  checkout  and  debugging  remains  an  art  to  be  performed  in  a 
painstaking  fashion. 
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V.  ROLES  OF  COMPUTER  MODELS  IN  COMMAND  AND  CONTROL  ANALYSIS 


Simula'; ion  language  computer  models,  such  as  that  repre- 
sented by  the  GPSS  CATCC  model,  can  serve  several  roles  in 
command  and  control  analysis  (cf,  Ref.  1,  1974,  pg.  64):  (1)  to 

answer  questions  about  the  status  of  systems  effectiveness, 

(2)  to  diagnose  system  problems,  and  (3)  to  predict  future 
system  performance  and  effectiveness.  In  all  of  these  roles,  the 
computer  model  offers  much  more  power  and  flexibility  with  regard 
to  manipulating  system  parameters  and  reconfiguring  the  system 
than  is  possible  when  attempting  to  examine  the  operation. al 
system  directly.  On  the  other  hand,  it  is  not  ordinarily 
possible  to  check  the  validity  of  each  and  every  variation  of 
the  computer  model,  and  often  the  validity  of  results  is  either 
estimated  or  is  simply  unknown.  In  the  end,  a blending  of 
analytical  techniques,  including  direct  empirical  testing,  at 
critical  points  is  probably  necessary,  giving  some  assurances 
but  no  overall  guarantees  of  validity. 

SYSTEM  EFFECTIVENESS  QUESTIONS 

If  only  system-global  or  final  status  measures  of  effective- 
ness are  needed,  a computer  simulation  may  need  only  represent 
the  overall  system  and  a detailed  simulation  of  components  or 
subsystems  may  be  unnecessary.  The  performance  of  the  system  can 
be  made  to  depend  on  the  level  of  load  or  environmental  condi- 
tions, which,  in  the  case  of  CATCC,  could  include  parameters 
such  as:  the  number  of  aircraft  in  each  "light,  the  rate  of 

arrival  of  flights,  mixes  of  aircraft  types,  pilot  proficiency 
as  evidenced  in  flight  errors,  and  fuel  condition.  Specific 
events  may  also  be  pertinent,  such  as  the  turning  of  the  carrier 
to  a new  heading  or  the  bolter  of  an  aircraft.  Performance  and 
effectiveness  may  be  investigated  as  a function  of  these 
parameters  or  events  if  the  design  of  the  model  included  the 
appropriate  features;  for  example,  if  parameters  relating  to 
number,  type  and  arrival  of  aircraft  are  of  interest,  tnen  the 
model  must  include  entities  which  correspond  to  individual 
aircraft. 

Given  an  appropriate  computer  model,  the  appropriate 
parameters  may  be  varied  as  necessary,  and  resulting  performance 
measured.  Since  GPSS  permits  multiple  runs  to  be  made  with 
convenience,  an  experimental  design  may  be  implemented  and 
sufficient  data  collected  for  statistical  analysis.  While  large 
and  costly  computer  runs  may  be  involved  for  large  numbers  of 
iterations  with  a large  model,  it  should  be  clear  that  perform- 
ance data  may  be  collected  on  situations  which  may  be  exceedingly 
difficult  or  impossible  to  collect  during  a field  experiment 
involving  an  operational  command  and  control  system. 
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SYSTEM  DIAGNOSIS  QUESTIONS 


Suppose  that  the  measures  of  effectiveness  for  a given 
system  indicate  a deficient  level  of  performance.  How  should 
one  correct  the  situation?  As  suggested  in  Finley,  et  al  (Ref. 
1,  P.  67) , one  may  attempt  to  adjust  the  system,  or  failing  in 
this,  faulty  components  may  be  replaced.  While  the  procedure 
may  be  basically  trial-and-error , one  must  be  guided  by  some 
prior  and  much  more  detailed  knowledge  of  operational  system 
response  to  specific  changes  if  some  degree  of  efficiency  is  to 
be  achieved. 


As  pointed  out  in  the  preceding  discussion,  an  iterative 
procedure  will  be  difficult  and  costly,  and  often  too  dangerous 
or  impossible  to  implement  with  an  experimental  approach  using 
the  operational  system.  A computer  model  is  relatively  simple 
and  less  expensive.  Deficiencies  may  be  systematically  included 
in  the  model  in  varying  degrees  of  severity  and  the  effect  on 
measures  of  effectiveness  observed;  however,  this  is  limited  to 
variation  in  the  parameters  provided  in  the  model. 

Through  use  of  a more  complete  model  than  would  be  used  to 
investigate  a status  question,  the  sensitivity  of  system 
performance  to  changes  in  parameters  representing  the  more 
detailed  and  internal  operations  of  the  system  can  be  found, 
allowing  (1)  the  system  characteristics  to  be  identified  which 
might  cause  a specific  deficiency,  and  (2)  a determination  of  the 
amount  of  adjustment  which  may  be  needed  for  correction.  Of 
course,  exercising  the  model  in  this  manner  should  only  be 
necessary  to  provide  knowledge  about  system  mis-operation  and 
sensitivity  to  internal  changes  when  such  knowledge  is  not 
available  or  testable  through  operational  experience.  Ultimately, 
in  any  case,  changes  must  be  tried  in  the  operational  system,  and 
measures  of  effectiveness  collected  to  determine  if  the  fix  was 
appropriate . 

SYSTEM  PERFORMANCE  PREDICTION  QUESTIONS 


The  computer  model  may  be  used  to  predict  system  performance 
and  effectiveness  with  much  the  same  objective  as  the  approach  to 
system  diagnoses.  The  question  is  put  in  the  form:  What  will 

happen  if...?  If  the  model  is  constructed  appropriately, 
variations  in  model  parameters  or  configuration  may  be  introduced. 
Since  many  inputs  and  parameters  may  be  stochastic,  multiple 
computer  runs  may  be  necessary  to  establish  a sufficient  statis- 
tical set  of  measures  for  evaluation.  Based  on  this  procedure, 
statements  may  be  made  to  the  effect  that  substitutions  in  either 
the  man  or  machine  components  of  the  system  (or  AX  change  in  a 
man  or  machine  parameter)  will  make  an  average  improvement  AY  in 
system  performance.  If  such  a prediction  can  be  related  to  each 
change,  then  a regression  equation  may  be  formed  with  change 
variables  and  coefficients  written  on  the  left  side  of  the 
equation  and  the  equation  and  the  predicted  variable  (measure  of 
effectiveness)  on  the  right-hand  side. 
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It  should  be  clear  that  while  questions  of  system  effective- 
ness status  may  be  approached  with  a global  model,  questions 
about  system  effectiveness  diagnoses  or  prediction  require  a 
model  with  much  internal  detail.  For  example,  if  man-machine 
performance  is  to  be  addressed,  the  people  of  the  system  must  be 
modeled  along  with  specific  displays  and  man-machine  and  man  man 
interfaces.  Consequently,  model  complexity  is  increased, 
requiring  more  model  development  and  validation  effort. 

DEVELOPMENT  OF  MEASURES 

The  development  and  selection  of  a reliable,  valid  and 
useful  measures  set  is  often  a difficult  task.  When  measuring 
in  the  operational  environment  one  should  be  certain  that  the 
measures  set  is  the  best  possible.  Consequently,  there  is 
reason  to  use  the  computer  model  as  a testbed  for  measurement, 
so  that  alternative  forms  can  be  compared  and  combined  in  an 
environment  which  is  conducive  to  measurement  development. 
Further,  many  forms  of  measurement  are  so  difficult  to  collect 
in  the  operational  environment  (e.g. , those  which  require  a large 
amount  of  information,  reflect  fast-happening  events,  or  require 
extensive  computation)  that  they  are  precluded  from  use  in  the 
operational  environment  unless  the  payoff  can  be  demonstrated. 

The  computar  model  will  permit  study  of  any  mathematically 
expressible  form  of  measurement  whenever  the  model  includes  the 
quantities  which  are  required  for  computing  the  measure. 

ROLE  WITHIN  THE  TOTAL  COMMAND  CONTROL  ANALYTIC  PROCESS 

The  computer  model  can  be  a powerful  tool  for  the  analysis 
of  command  and  control  systems;  however,  it  should  be  used  in 
context. with  other  analytic  methods  and  in  conjunction  with 
empirical  tests.  The  computer  model  is  based  on  other  modeling 
efforts  (e.g.,  models  of  the  human  components)  and  is  used  as  a 
substitution  for  empirical  tests.  Consequently,  the  computer 
model  is  an  outgrowth  of  other  analytic  methods,  represented  in 
a form  which  gives  additional  power,  but  which  ultimately  is  an 
adjunct  to  empirical  testing. 

Normally,  the  computer  model  is  neither  used  at  the  begin- 
ning or  the  end  of  the  analytic  process  since  prior  analysis  is 
usually  needed  to  specify  the  computer  model  and  the  results  of 
computer  model  computations  are  normally  a preliminary  to 
further  analysis  or  empirical  tests.  Otherwise,  of  course,  the 
role  of  the  computer  model  within  the  total  analytic  process 
depends  on  the  purpose  to  which  it  is  applied.  The  computer 
model  is  truly  a tool  with  many  uses. 

INCORPORATION  OF  HUMAN  OPERATOR  MODELS  AND  PSYCHOLOGICAL  THEORY 

The  computer  models  discussed  in  thi~  paper  are  basically 
task  descriptive  models  wherein  each  action  taken  by  human 
operators  can  be  included  as  a system  event.  Of  course,  for  the 
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computer  model  to  work  properly  each  event  must  be  caused  to 
occur  for  the  proper  combination  of  stimuli  and  at  the  proper 
time.  In  the  most  basic  form,  then,  the  computer  model  must 
include  at  least  the  characteristics  for  nominal  and  consistent 
human  operators.  The  human  operator  can  be  readily  embellished 
with  some  realistic  operator  characteristics  by  altering  the 
event  times,  by  including  alternative  stochastic  distributions 
so  as  to  allow  for  human  variation  as  a function  of  conditions, 
and  by  incorporating  known  human  errors  which  occur  with  defined 
probability.  In  this  manner  a human  operator  model  can  be 
developed  for  each  workstation  which  will  agree  with  observation 
and  data. 

The  various  parameters  of  che  human  operator  model  which 
control  the  distributions  of  time,  error  and  laternative  actions 
can  also  be  variable.  Consequently,  to  the  extent  that  these 
factors  are  known,  the  model  parameters  can  be  changed  to  include 
the  effects  of  fatigue,  motivation,  training,  etc.  Or,  if  one 
wishes,  the  model  parameters  can  be  changed  systematically  so  as 
to  reflect  command  actions  and  to  determine  their  effect  on  the 
overall  system  performance,  to  infer  the  sensitivity  of  the  system 
to  the  effects  of  fatigue,  motivation,  training,  etc. 
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VI.  DISCUSSION 


One  of  the  advantages  provided  by  a computer  model  is  the 
relative  richness  of  the  form  of  task  description  involved. 
Simulation  language  computer  models  incorporate  timing  of  events, 
sequencing  of  tasks,  interaction  between  task  elements,  and  the 
competition  of  time-shared  and  over-loaded  tasks.  Further,  task 
performance  variables  can  be  made  to  operate  stochastically  and 
alternate  distributions  can  be  used  to  reflect  the  effects  of 
training,  changed  standards,  motivation  fatigue,  etc.;  that  is, 
the  effects  of  changes  in  factors  that  can  be  modified  by  command 
action.  However,  the  richness  of  task  description  presents  a 
problem  to  the  analyst/programmer  defining  the  computer  model. 

The  analyst/programmer  has  at  his  disposal  a model  which  is 
capable  of  representing  an  operator's  task  at  many  descriptive 
level,  from  simple  to  highly  detailed.  As  with  any  simulation 
development,  the  designer  is  faced  with  the  difficult  decisions 
associated  with  determining  the  necessary  fidelity  of  simulation. 

A level  of  specificity  must  be  determined  which  is  adequate  for 
model  validity  but  which  also  restrains  the  cost  of  collecting 
information  needed  to  fix  model  parameters.  As  the  model  becomes 
more  complex,  more  information  about  the  real  system  is  needed. 

The  analyst/programmer  determines  the  mapping  from  the  descrip- 
tion of  the  system  provided  him  (probably  overly  simple  and 
incomplete)  and  the  success  of  the  model  will  depend  on  how  well 
the  analyst/programmer  has  done  this  mapping  process.  This  at 
present  is  a complex  creative  process. 

The  type  of  computer  model  described  in  this  report  causes 
simulated  events  to  occur  in  proper  timing  and  sequence.  This 
requires  timing  information  for  each  operator  activity  to  be 
assessed.  The  time  (or  distribution  of  times)  for  each  operator 
activity  requires  detailed  knowledge  of  operational  task  perform- 
ance or  the  ability  to  make  accurate  estimates.  Knowledge  is 
also  required  of  the  tasks  that  are  rather  continuously  performed 
or  which  are  self-initiated;  often  only  the  tasks  which  are 
initiated  by  external  events  are  clearly  defined.  Also,  the 
computer  model  will  be  affected  by  the  flexibility  of  the 
scenario  provided:  a simple  constrained  scenario  will  require 

only  simulation  for  a highly-specif ic  combination  of  circumstances; 
a more  general  scenario,  or  a set  of  scenarios,  will  require  a 
more  complex  model  and,  correspondingly,  much  more  information 
about  parameters  of  the  system.  Similarly,  information  needed 
for  the  resultant  model  will  depend  on  the  specificity  to  be 
included  about  operator  functions  and  decisions. 

While  the  richness  of  description  provided  by  the  computer 
model  may  initially  pose  some  problem  due  to  insufficiency  of 
information  provided  by  the  usual  task  analysis  methods,  the 
potential  exists  for  advancing  the  state-of-the-art  in  human  task 
description.  If  a task  descriptive  method  is  to  be  effective  for 
systems  in  which  task  execution  time,  time-sharing  of  tasks,  and 
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interdependencies  between  tasks  are  important,  then  the 
information  required  by  the  computer  modelling  method  must  be 
made  available.  In  a sense,  the  computer  model  is  a new  task- 
analytic  method  and  it  must  be  formalized  into  a clear-cut  set  of 
task-analytic  procedures.  The  procedures  for  describing  the 
system  operators,  equipment  displays  and  communications  as  given 
in  Chapter  III  constitute,  in  fact,  a new  task/system  description 
method  which  appears  to  be  far  richer  than  the  methods  presented 
in  Figures  5-7.  See  Reference  2 for  a further  discussion  of 
this  issue. 

Based  on  the  examples  developed  anc  tested  for  this  paper, 
it  is  believed  that  the  C&C  Analysis  Model,  using  GPSS  or  a 
similar  language,  can  serve  an  important  role  in  the  evaluation 
of  manned  systems  and  their  command  and  control  elements.  A 
powerful  technique  results  when  the  personnel  and  machine 
components  of  a total  man-machine  system  are  described  both 
appropriately  and  in  compatible  terms:  this  is  permitted  by 

simulation  languages  like  GPSS.  Given  a valid  computer  model 
which  extends  over  both  personnel  and  machine  components,  the 
analyst  can  address  questions  of  systems  effectiveness  and 
performance  status,  diagnosis  and  prediction.  From  a composite 
view  of  the  total  man-machine  system,  enlightened  analysis  and 
design  can  proceed;  and,  when  the  model  is  in  a working  format 
such  as  with  a GPSS  computer  model,  innovations  can  be  tested  to 
determine  their  utility. 

It  is  not  contended,  however,  that  the  computer  model 
approach  will  always  be  more  cost  effective  than  direct  empirical 
assessment.  It  will  often  be  practical  to  address  difficult 
questions  with  a computer  model  instead  of  direct  measurement  on 
the  system  due  to  the  difficulty  and  high  cost  of  measurement  in 
the  operational  environment.  On  the  other  hand,  high  costs  for 
computer  model  development  should  be  anticipated  when:  (1)  high 

fidelity  of  simulation  is  necessary,  or  (2)  information  needs  are 
very  simple  and  easily  obtainable.  Cf  course,  once  data  are 
collected  and  a model  is  constructed,-  many  measurements  under 
many  model  variations  are  possible,  and  the  use  of  a model  may 
greatly  reduce  costs  compared  to  direct  system  measurement.  But, 
it  must  be  kept  in  mind  that  a computer  model  must  be  validated 
with  some  empirical  tests  prior  to  use.  Consequently,  if 
information  needs  can  be  easily  satisfied  by  simple  empirical 
tests  (compared  to  those  required  for  model  validation) , use  of 
the  computer  model  will  not  be  cost-effective.  It  may  also  be 
seen  that  the  overall  effort  required  for  model  development  is  a 
combination  of  empirical  and  analytic  efforts,  and  never  purely 
an  analytic  effort. 

Taking  the  above  considerations  into  account,  it  is  believed 
that  the  simulation- languages  computer-model  approach  will  often 
be  cost-effective  for  the  evaluation  of  command  and  control 
element  in  manned  systems.  Further,  such  models  can  integrate 
existing  analysis  methods  which  are  now  separate,  provide  an 
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advanced  technique  for  task  description,  and  provide  a vehicle 
for  the  integrating  of  psychological  theory  into  man-machine 
analysis . 
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APPENDIX  A.  COMPUTER  PROGRAM  LISTING: 
A SIMPLIFIED  GPSS  MODEL  OF  CATCC 
(VERSION  1) 


GP3S  M 0 O' L OF  CATCC 


* ¥ 4MM 


THIS  IS  A VERY  3IMPLr  ~ i.  H P ~ S F N T A T 1 0 N OF  CATCC.  IT  IS  INTENDED 
ONLY  AS  A i T F A W “ A N FOR  DISCUSSION  WITH  K-GARD  TO  FURTHER  USF  AND  D£\ 
AT  THIS  POINT  IN  DEVELOPMENT , NO  ATTEMPT  IS  FADE  TO  CONTROL  A/C  f 
RUT  TP  SPACING  ROUGES  TO  XC  SEC.  OP  LESS,  AN  A/C  IS  DIVERTED  TO  AN 
S°ACc  FA-THE-  HACK  IN  T«~  APPROACH. 

MOE  INCLINE  F>rQUrNCY  L’  I S T R I OUT  I C NS  OF  THE  FQLLOWlNG-- 
(11  A/S,  HOG,  AND  G/S  E:;RCCS 
<2)  FUEL  -cUAINI:r-  AFTER  RECOVERY 

(3)  CONTROLLER  PROCESSING  TIME 

(4)  A/C  SPACING 

(5)  -fCCVERY  TIME 


l**  ■?.  W.  0--E-HAV-O  5/17/74  VERSION  1 


PARAMETERS  APE  ASSOCIATED  WITH  EACH  TRANSACTION  IN  THE  FLOW 
PARAMETER  DICTIONARY 


- flight  N U m E E c ( + 50  IF  BOLTER i *70 

- FLIGHT  site 

- TV»E  a/C 

- SERIAL  NU  -1°  rR  (CHANGED  IF  BOLTER ) 

- SECONDS  OF  rU CL  F-MAINING 

- CLOCK  TIME  STORAGE 

- AI  R$  P Cr  J - SECONDS  P~°  HI,  E 

- MEAT  INC-  EPPQP  - CD G -FEES 

- GLKESLPE  E J R 0 R - FoET 

! - CHECKPOINT  - MILES  TO  GO 

- HOLDING  TINE  ( = 1 C IF  p^EV  BOLTER) 

* - CLOCK  TINE  FLT  ARRIVES  AT  MARSHAL 


OOLTE  0 


SAVPVALUfS  A r%E  STORAGE  LOCATIONS  FOP  THE  M" MOR Y 0F  SPECIFIC  VALUES, 
and  TABLES  of  INFORMATION  IKE.  STATUS  BOARD  INFORMATION  AND  OTh£R 
0°E  c A T 0 = DISPLAYS) , 


3 AVS V ALUE  DICTIONARY 


■Y£C  - TI »•£  LAST  A/D  REPORTED  CHECKPOINT  1,2,  ...2C 
- I MCE  E *!ENT  FLT  NO  yy  ICC 
1 - TIME  SEP  POP  LAST  REPORTING  A/C 

I - $rRI A L NO  POP  A/C  TO  ^E  TESTED  AND  GIVEN  CO-MAND 


MILES 


- A/S  CONTROL 

- HOG  CONTROL 

- G/S  CONTROL 

- COLTER  A/C  HOLDING  TIME 


xn:  - time  pop  LAST  A/C  FLIRTING  IN  AT  S^ECIFC  CHECKPOINT 
X 4 1 - LAST  CLOCK  TIME  TO  START  APPROACH  ASSIGNED 
X42  - COUNTE5  FOR  A/C  LANCING  WITHIN  EA.  ^ LT . 

XSl-X’O  - A/C  NO.  3Y  DI3T.  TO  GO  (PROGRESS  DISPLAY) 
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TIME  FOR 

RECOVERY 

OF 

FLT 

3 v a^iayle 

C2-<1 

6 

S°L  IT 

V 3 » Mr <T  ,4 

C-EAT 

E INDIV 

. A/C  ANO 

SERIALI7 

E P* 

7 Nr 

VT  ASSIGN 

7, <24 

VELOC 

IT  Y 

IN 

F 7 

5 VA»IA9Lr 

FNl*K5*Kl*4t} 

8 

ASSIGN 

5 ,V5 

FUEL 

REGAINING  (SEC) 

IN  P5 

* MARSHAL.  ASSIGN  TINE  TC  START  APPROACH  (1-HIN  APAPT) 


9 K4R< 

h VA  R I ABLE 

C assign 

t TEST  G 

2 ‘fAVtVAUJf 

3 MACSH  T«?  s T L£ 


l 

* 

• j I mUl  A T E APPROACH  ONE  MILE  AT  A TIME 


4 

ASSIGN 

t C » K ? J 

ri”  USFU  AS  L COP  COUNTER,  MILES  TO  GO 

5 

RE  GIN 

ASSIGN 

7 ♦ , F ME 

A/S  FPRCP  IN  P7 

e 

ASS  TON 

8 ♦ , F N T 

L-R  ERROR  IN  ?8 

7 

assign 

0 ♦ , F N 1 

G/S  E R ROR  IN  RO 

* 

ASSIGN 

6, Cl 

ARRIVAL  TIMS  RECORDED  IN  Pb 

9 

split 

1 , 0 A T A 

SEND  X ACT  WITH  DATA  IN  PA»AMETE°S  TO  OATA  BELOW 

C 

aovance 

P 7 

AOV  CLOCK  TIME  TO  TRAVEL  A MILE 

1 

ASSIGN 

, or 

DECREMENT  FUL  L REMAINING 

2 

GATE  LS 

1 , SKIP 

LET  X AC  T THRU  IF  CONTROL  ACTIONS  NEEDED 

3 

TEST  E 

Vtl,x >J,SKIR 

CONTROL  ONLY  PROP"*'  A/C 

4 

SAVFVAL'JE 

2 J ♦ K 0 

CLFAR  A/C  10  FLAG 

5 

LOGIC  5 

1 

FESET  TO  CLOSE  GATE  AGAIN 

11 

VARIABLE 

PI  f n4 

f. 

ASSIGN 

7 , V ?7 

CONTROL  A/S 

7 

A 3 S I G N 

8 , X ? 8 

CONTROL  heading 

ri 

ASSIGN 

0 , X ? 9 

CONTROL  GL  IOt  SLOPE 

9 

A S f y f,N 

1 1 , x r j 

MOLDING  T I *1c  INPll 

1 

t:~t  ne 

Fll.KC, SKIP 

TEST  TO  SrE  IF  BOLTER  A/C 

1 

op  I NT 

, ,p 

PRINT  PA^AMETFR  VALUES 

PJ  I NT 

M,  Fi,y 

PRINT  PROGRESS  DISPLAY 

3 

A07AflCr 

x n 

HC’LO  FOR  Tme  hue  commanded 

«4 

S A7LVALUE 

3 , K : 

ClE  A p BOLTER  FLAG 

9 

ASSIGN 

1 1 , K 1 9 

CLFAR  FLAG,  INOIC  PRcV  BOLTER 

e 

assign 

c - , X 3 r 

DLC’fMtNT  FUrL 

7 

PRINT 

,,p 

8 

P 5 I NT 

r’  1 , 7 1 , ¥ 

PRINT  PROGRESS  0 1 3 DL  A Y 

9 

SKIP 

•TUFFS  R 

O 

u 

LOOP 

1?  tncr,r  N 

Kr  fP  LOOPING  UNTIL  20  MILlS 

UPOATE  3 I A T 1 5 

TICS 

l 

TEST  Lc 

pi  ,<H0  ,TA»VJL  PRINT  AS  E A A/C  Of  FIRST  FLT  LANDS 

2 

PRINT 

♦ ,P 

F‘INT  PARAMETER-*  AS  EACH  A/C  LANCS 

3 

P R T N T 

1 , 7 1 , X 

OUTPUT  ALL  SAVEV4LUES 

4 

TAPQL 

TABULATE 

1 

UPOATE  A/S  TAJLE 

*; 

TA  OULATE 

n 

c 

U PQA  T c HOG  TABLE 

r* 

T AHUL  ATT 

3 

U p 0 A T L G/S  TABLE 

7 

T AflUL  AT  F 

4 

UPQATF  FUrL  TABLE 

8 

1 A °UL  AT  F 

•» 

UPDATE  TkANSIT  TIME  TABLE 

1 8 

V APIA  RLE 

X ♦ K 1 

9 

S4'/c  V ALUf 

42,  VI  8 

USE  XL?  A L A CQUNTF.H 

0 

T - “ T GE 

xu?  ,P2,  JIJHP 

IP  X«2  GE  NO.  IN  FLT  TAB  PlCuV-f  y TIME 

t 

T A °UL  A T r 

4 

TABULATE  FECOVEKY  time 

2 

SA'/iEVAl  UF 

A2  ,K0 

F'tSET  COUNTER 

3 

MUMP 

TEPHINATI 

1 

‘4 


• SIMULATE  rONTCOL  FUNCTIONS 

4 OATA  MARK 

5 TEST  Lc  01. <20. TERM  00  NOT  PERMIT  UUEUE  TO  HZ  LONGER  THAN  20 

e QUtUE  t JOIN  QUEUE  35 

— **■  ■ ™— ——————  in  ua^555E&x:  •"  — — 


RrlCQRO  START  TIME  FUR  INUIV  A/C  TRANSIT  TIME 

F Nu ♦ C 1 

<j,Vf>  START  APPPACH  TIME  IN  Pb 

Pb,X41, MARSH  TFST  TIME  TO  START  SAVEO  IN  XM 

41, °b  SAVE  LATEST  EAT  IN  X41 

Pb,Cl  A/C  HELD  UNTIL  TIME  TO  START  APPROACH 


■ ..  If!  u Lf|»_ 


IP* 


i 

j 7 

- 

S£  I Z " 

1 

8 

0 E° A 5 T 

1 

! o 

> 

SAVEVALUE 

4 0,  X*  10 

| C 

SAVFVAlUE 

° 1 0 » PS 

1 A 

VA°I ABLE 

P10+KNC 

, . 1 

SAVE  VALUE 

V 1 4 , V 1 1 

p 

SAVEV ALUt 

71, Cl 

j 1 3' 

advance 

5,2 

1 «• 

54VEVALUE 

22 , V10 

r 

T A BULAT  r 

6 

( 

10 

VA^Ifl RLE 

°6- V4 j 

• 6 

TEST  LE 

vio , kb: 

4 

BOLTER  CONTROL 

LOGIC 

l 7 

SAVEVALUc 

23,  Vll 

L 0 G I S 

1 

<3 

SAVEV  ALUE 

27 , K?L 

1 0 

SAVEV  ALU: 

2i  , ^8 

1 

SAVE VALUE 

29,  p9 

15 

VARIABLE 

fns*kgo 

2 

SAVE  VALUE 

31,715 

3 

ASSIGN 

»♦  +■  , F M 5 

A 

ASSIGN 

1 + , K E o 

G 

TEST  LE 

P10,K4, 

IE 

VARIABLE 

X 30  hF  N5 

e 

ASSIGN 

*4  + , F N 5 

j 7 

ASSIGN 

1+  ,K2I 

1 3 

SAVE  VALUE 

3 I , Vlb 

j 9 

OF  E V B 

T-ST  G 

^1 1 , K 0 , 

1 

17 

VARIABLE 

X3C+K6C 

C 

SAVEV AlUl 

3 C , V 1 ^ 

1 

EMO 

RELEASE 

1 

' 2 

TABULATE 

5 

1 3 

* 

cm 

terminate 

* 

4444«444*»44*444# 

*444444 

4 

INSURE  AN  EVENT 

OCCURS 

4 

GENEPAT- 

6 C 

5 

4 

T£=>MTNAT: 

4 4 4 4 4 44  4*  4 » 

4 

4 

4 

TA">L 

= DEFINITIONS 

* 

EACH 

TA3LE  IS  A 

FP-DUE 

4 

AI^SPEEO  (S 

EC/MI  ) 

1 

TA3LE 

°7, 1C  ,1 

4 

HEADING  EE- 

OR 

2 

TABLE 

P8,-50, 

4 

glide  sloce 

£E  E0° 

• 

3 

T ABLC 

R9,-50, 

4 

FUEL  REGAINING  ( 5E 

4 

TABLE 

F5 , o«i: 

4 

cdntedllE F 

I NFC 

5 

TABLE 

M 1 » 0 t 1 • 

4 

A I R C c A F T SPACING  ( 

6 

T A nL  r 

X22,C,1 

4 

INDIVIDUAL 

A/C  T-A 

7 

TABLE 

Ml  , 36  3, 

OBTAIN  CONTROLLER 

DEPART  FROM  QUEUE 

TIME  LAST  A/C  AT  CHICKFT  IN  XLO 

S T 0 D t ARCIVAL  time  in  savevalue 

UPDATE  PROGRESS  TABLE 
P.fCDRC  TIME  OF  UPDATE 
DELAY  5 ♦■/  -2  SECONDS 

STORE  SEP  (LATtR  OIFF  STORE  FOR  E A C HKPT ) 


, E NO  TEST  IF  SPACING  . LT  . 3:  SEC. 

IDENTIFY  A/C  FOR  BOLTER 

SET  FOR  CONTROL  3 AT:.  IN  APPROACH  LOOP  ABOVE 
AIPSP'ED  SET  TO  NOMINAL  VALUE 
NC  CONTROL  FOR  NON 
NO  G/S  CONTROL  FG\  NOW 

X3C  CONTAINS  THE  COMMANDED  HOLDING  TIME 
ASSIGN  NO  EQUAL  TO  A/C  JUST  BEHIND  CLOSEST  S^ACi 

FREV3  WITHIN  4 MI  OF  DECK,  INTEGRATE  FARTHER  BACK 
*KBG  ♦ KoQ 


1 


:nt 


HOLDING  TIME  TO  GET  TO  NEXT  FARTHER  SPACE  IN  X 3C 


RELEASE  CONTROLLED  FC 5 ANOTHER  JOB 

update  info.  proc.  table 


^ 1 w • 


°E "C  Vr  ° Y TABLE 
8 TA~LE 


MF12, 3C3,3C,9; 


RUN  SIMULATION  FQD  THr  RECOVERY  Oc  A NUMBER  OF  FLIGHTS  TO  COLLECT  AN 
AOEQUATE  SAMPLE  FOc  STATISTICAL  ANALYSIS. 


START 


ICO 


36 


APPENDIX  B.  COMPUTER  PROGRAM  LISTING: 
AN  EXPANDED  GPSS  MODEL  OF  CATCC 
(VERSION  2) 


37 


SITUATE 


GP3S  MODEL  OF  CATCC 


I**,*,*#***.**.  « » « « a J 


MCE  INCLUDF  FREQUENCY  Q ISTRIOUT  ION'S  OF  THE  FOLLOWING* 
(1)  A/S » HOG,  ANO  G/3  E=>PCRS 
( 2 » FUFL  REGAINING  AFTER  RECOVERY 
(5)  RECOVERY  timf 


♦**  R.  W.  OBERmAYER  1G/17/74  VERSION  2 


PARAMETER  DICTIONARY 


FLIGHT  NUMBER 
FLIGHT  SIZE 
TYPE  A/C 

SERIAL  NUM5"R  (CHANGED  IF  3QLTEB ) 
SECONDS  OF  FUEL  REMAINING 
CLOCK  T T ME  STORAGE 
AIRS^EEC  - SECONDS  P£R  MILE 
HEADING  ERROR  - OSGREEES 
GLIDESLPE  ERROR  - FEET 
CHECKPOINT  - MILES  TO  GC 
HOLDING  TIM" 

• CLOCK  TIME  CLT  ARRIVES  AT  MARSHAL 


SAVE VALUES  APS  STORAGE  LOCATIONS  FOR  THE  MZMOPY  OF  SPECIFIC  VALUES. 
ANO  T A 3 L r 3 OF  INFORMATION  (I.t.  STATUS  BOARO  INFORMATION  ANO  OTHER 
OPERATOP  DISPLAYS). 

SAVtVAL’JE  DICTIONARY 

y i - Y ? . - f • LAST  A/C  REPORTED  CHECKPOINT  1,2,  ...20  MILES 

X2L  - INC-EMENT  FLT  NO  3Y  100 

X23  - SERIAL  NO  PC3  A/C  TO  BE  TESTED  ANO  GIVEN  COMMAND 
X 24  - A/S  CONTROL 
X25  • WAC- 

X42  - C CUNT • f OR  A/C  LANDING  WITHIN  EA.  !"LT • 

X90,X»01-X4CO  - STATUS  BOABD  DATA 

X13P.X1G1-X3QC  - cAO  A R/O  J S°L  AY  DATA 
X 3 ,XB3  - SCAN  COUNTERS 

XS6.X97  - OISTANCES  FOP  THE  TWO  A/C  TO  3E  COMPARED 


‘FACILITY  ASSIGNMENTS' 

1 CCA 

2 MC 

o STATUS  PC  UPKP 

4 APPROACH  A 

5 APPROACH  9 

6 FINAL  A 

7 FINAL  B 


• r- 


1 '-'H’v  1 


¥ ¥ ¥ ¥ ¥ ¥ ¥ 

l ¥ ¥ ¥ J 

* BEGIN  PROGRAM 

¥ ¥ ¥ ¥ ¥ 

k • * ♦ • 

♦ THE  l 

FOLLOWING  ARE 

FUNCTIONS 

(I.F.  O I STRI BUT IONS!  USED  IN  THE  GP5S 

j 

• SIMULATION.  FUNCTIONS  1-3 

ARE  NORMAL  RANDOM 

DISTRIBUTIONS  USED 

FOR 

i 

* THE  GENERATION 

OF  FLIGHT  ERRORS. 

FUNCTIONS 

4 and  5 

ARE  i 

USED 

: 

• IN  THE  ASSIGNMENT  OF 

EAT  AND  FOR 

A/C  BOLTER 

INTEGRATION. 

1 FUNCTION 

RM1.C56 

* ¥ 

• 

¥ 

¥ 

¥ 

¥ 

¥ 

¥ 

¥ 

¥ ¥ 

.0  -100. 

. o rc  o 3 

-40. 

.00  023 

-35. 

.00135 

-30. 

. 0 026 

-28. 

. 00  47 

-26. 

\ 

• COM2  -24. 

.0139 

-22. 

. 0227 

-20  . 

. 0287 

-13. 

.0359 

-18. 

,0*46 

-1  7 • 

.0548  -1*. 

.0668 

- 15 . 

,0808 

-14. 

. 0968 

-13. 

.1151 

-12. 

.1357 

-11 . 

.1*587  -10. 

.1841 

-9. 

.2119 

-8. 

, 2** 20 

-7. 

.2743 

-6. 

. 30  85 

-5. 

4 

» 3446  -4. 

. 382  1 

- 3 . 

. 4207 

-2. 

. 4 6 C 2 

-1. 

.500 

O.C 

.5  398 

1. 

4 

.5703  ?. 

.6179 

3. 

. 6554 

4. 

.6915 

5. 

.7257 

6. 

.7580 

7. 

; 

.7881  8. 

.8159 

9. 

. 8413 

10. 

. 8643 

11 . 

. 8849 

12. 

. 90  32 

13  ♦ 

1 

.9192  14. 

.93.32 

15. 

. 94*52 

16. 

. 9554 

17. 

.9641 

18. 

.9713 

19. 

.9773  20. 

.9861 

22. 

. 9918 

24. 

. 9953 

26. 

. 9974 

28. 

. 99865 

30  . 

. 

.999tt  35. 

.99997 

40. 

1 

2 FUNCTION 

RNi.Cll 

• ¥ 

¥ 

• 

¥ 

¥ 

¥ 

¥ 

¥ 

¥ 

¥ 

¥ ¥ 

i 

.0  -7.50 

. 03C  03 

-3.0 

.00135 

-2.25 

. 0227 

-1.5 

.1587  . 

-.75 

.500 

0. 

l 

,8413  .75 

.977.3 

1.60 

. 998652.25 

. 999973.0 

.999997,50 

• 

3 function 

9N1.C1 

T 

* 

¥ ¥ 

* 

¥ 

¥ 

¥ 

¥ 

¥ 

¥ 

¥ 

¥ 

¥ ¥ 

. 0000  3-  1 3. 

.0026 

-7. 

. 0 0 82 

-6. 

. 0 227 

-5. 

, C 5 48 

-4  • 

.1131 

-3. 

i 

.2119  -2. 

. .344  6 

* 1 « 

.500 

0. 

. 6564 

1. 

. 7881 

2. 

.8849 

3. 

j 

.944524. 

.'*''73 

5. 

. 9918 

6. 

. 9974 

7 . 

.9999710. 

1 

* IN  THE 

FOLLOWING  FUNCTIONS  FOR 

EAT  ASSIGNMENT  AND 

1 HOlTER  INTh 

ORATION* 

• A SPACE 

13  Lr F T 

IN  TH^  APPROACH 

FQP  ANOTHER 

A/C  --(1-41 

SPACE  (5-9)  SPACE 

* ( IP- 15) 

5°  ACE  (16-211 

SPAC- 

(22- 

271  S°ACt  (28-30) 

■i 

4 FUNCTION 

°4 , 03  0 

i 

* * 

* 

♦ 

¥ 

¥ 

¥ 

¥ 

¥ 

¥ 

¥ 

¥ ¥ 

1 

t.  60. 

2. 

120  . 

3. 

180. 

4. 

240  . 

5. 

360. 

6. 

420. 

I 

7,  480. 

8. 

540  . 

9. 

600. 

10. 

720  . 

11  . 

780  . 

12. 

840. 

i 

13.  900. 

u. 

96  3. 

15. 

1 G 2 3 * 

16. 

1140. 

17. 

1200  . 

18. 

1 26  C . 

j 

19.  1320. 

20  . 

1 380. 

21. 

1440  . 

22. 

1560. 

23. 

1620. 

24. 

1^ 80  . 

25.  1740. 

26, 

180". 

27. 

1860  . 

2 8, 

1980. 

29. 

2040  . 

30. 

2100  . 

j 

5 FUNCTION 

F4 , Q3 0 

3 

j 

• ¥ 

* 

• 

¥ 

¥ 

¥ 

¥ 

¥ 

¥ 

¥ 

¥ ¥ 

■] 

1 4 

2 

3 

3 

2 

4 

1 

5 

5 

6 

4 

7 3 

8 

2 

9 

1 

10 

6 

11 

5 

1? 

*4 

13  3 

14 

2 

15 

1 

16 

6 

17 

5 

18 

4 

19  3 

20 

2 

21 

1 

2? 

6 

2 3 

5 

24 

4 

25  3 

26 

2 

27 

1 

**¥¥¥* 

2* 

**«*++  4 

3 

A ¥ » ¥ ♦« 

2'} 

i + «¥¥¥»  i 

2 

3a 

i ¥¥¥  + ¥¥< 

1 

!*»¥¥¥¥#¥¥¥ 

1 

¥ ¥ ¥ ¥ ; 

**•*•  VARIABLE  DEFINITIONS  •****■ 

,«»**««•»#**«»«*»»*****«*«**•*+**«*»*»******•*! 

1 

VARIABLE 

y ? 1 4 k ion 

".j 

2 

VAR  I ABLE 

FN  34 K 10 

3 

VARIABLE 

F?-K1 

1 

5 

VARIABLE 

FN1*K54K14400 

i 

6 

VAFlABLr 

<10*RN44P124K1200f 

\ 

11 

V A° I A BLr 

P14P4 

\ 

18 

VARIABLE 

V424N1 

j 

20 

VARIABLE 

K914PU*K1C  4*100 

] 

21 

VA°I ABLE 

y 1004K1 

j 

22 

VARIABLE 

y 9 7 4 K 2 5 

23 

variable 

K? 964  r4*K54  X90 

] 

j 

24 

V A°  I A BLE 

7904K 1 

25 

variable 

7984K 10 

26 

VARIABLE 

X96-7 97 

39 

j 

...28 

VARIA9LF 

yge-K6 

m mam  i ‘ JB 

29 

V A° I A PL  r 

X98-K9 

30 

VARIABLE 

y*?4-X  *6 

31 

VARIABLE 

K0-K4 

32 

variable 

X 9 8 - K 3 

33 

VARIA9LE 

K24-X*7 

* GENERATE  FLIGHTS,  Tine  IN  UNITS  of  1/10  SECQNO 

• 

1 GENE® ATF  30000, ,0  ONE  FLT  EVERT  HOUR 

2 SAVEVALUE  21, VI  TEMP,  STORE  LAST  FLT  NO. 

3 ASSIGN  1 , X 2 1 FLT  NO  IN  PI 

4 ASSIGN  2,V2  FLT  SIZE  IN  P2 

5 HARK  12  RFCORO  START  TIME  FOP  RECOVERY  OF  FLT 

6 S°LIT  V3,NEXT,4  CREATE  INOIV.  A/C  AND  SERIALIZE  P4 

7 NEXT  ASSIGN  7,K24  VELOCITY  IN  P7 

8 ASSIGN  5,V5  FUEL  REMAINING  (SEC)  IN  P5 


MAPSHAL,  ASSIGN  TIME  TO  START  APPROACH  (1-MIN  APART) 


9 

MA»K 

RcCORO  START  TIME 

FOR  INOIV  A/C  TRANSIT  TIME 

C 

SE I Zr 

11 

COMR 

OH  AN 

1 

ADVANCE 

100 

T 1 

2 

SEI7F 

2 

MC 

3 

advance 

ISO 

T 2 

5 

IN  P6  ? 

4 

ASSIGN 

6,  V6 

START 

APPRACH  TIME 

5 

ADVANCE 

20 

T 3 

1 

6 

SPLIT 

1 , SBO 1 

l 

i 

7 

RELEASE 

2 

8 

RELEASE 

11 

9(- 

} 

TRANSFER 

, MARSH 

■ 1 

•••••TIME  LOOP  -- 

MC  CHECKS 

MARSHAL 

A/C  PATTERN4 

0 

GENERATE 

1000, 900 

STM 

T6  - T 1 3 

i 

1 

SEIZE 

? 

2 

SEIZ® 

It 

3 

advance 

250 

4 

RELEASE 

11 

i 

5 

RELEASE 

2 

3 

' \ 

6 

* 

TERMINATE 

’ j 

• 

STATUS  BOARD 

A 

J i 

♦ 

SAVE  VALUE 

S LOCATION 

' < 

* 

TO 

DTG 

FUEL 

TIME 

REMARKS  fe 

* 

ACt 

301 

302 

3 C 3 

334 

3 C 5 

m 

AC? 

3 0 F 

307 

308 

309 

3 13 

* 

AC  3 

311 

312 

- 

- 

315 

* 

«• 

- 

- 

- 

- 

/ 5 

* 

AC?0 

3 RE 

3 97 

398 

399 

4 00 

* 

••••STATUS  ROAFO 

UPDAT ING*4 

+**#+** 

7 SBOl 

SET7E 

3 

8 

SAVF.  VALUE 

93  , K0 

G 

SAVEVALUF 

V 2 3 , V 1 1 

10 

0 

i( 

SAVEVALUE 

90  ,V24 

SAVEVALUF 

V 2 3 , P 1 0 

DTG 

2 

SAVEVALUE 

9 C , V?4 

3 

SAVEVALUE 

V 2 7 ♦ P 5 

FUEL 

REMAINING  (SLC» 

4 

SAVEVALUE 

90 , V2* 

5 

SAVEVALUE 

V 2 3 , C 1 

TIME 

OF  REPORT 

6 

SAVEVALUE 

90,  /24 

7 

SAVEVALUE 

V 2 3 , K 0 

REMARKKS 

a 

ADVANCE 

250 

4U 

RELEASE  ^ 

SFI?P  1 

advance;  ic 

RELE  ASC  1 

TERMINATE 

STATUS  ROA'-'D  UPDATE 
®T  SPLIT  1,SD01 

TRANSFER  ,P£T 


••••RADAR/niSPL AY  INFORMATION  UPDATING 


DISPLAY  INFORMATION 
SAVE  VALUE  LOCATIONS 


• 

PARA 

ACRFT  NUMOER 

m 

NO. 

1 

7 

3 4 

G 6 

10  

20 

« 

t 

m 

111 

121  131 

141 

191 

291 

! * 

2 

13? 

1 ! 2 

...  ... 

... 

1 *2 

292 

a 

3 

133 

... 

• •* 

193 

293 

1 • 

1 

U 

m 

i * 

t 

{ * 

1 0 

110 

120 

130  - -- 

20  0 

300 

o OI$p 

SAVEVALUr 

100, K0 

7 

savfvalue 

V20,P1 

(* 

SAVEVALUE 

100, V21 

Q 

<* 

savevaluf 

V?  3 , p ? 

c 

SAVE VALUE 

100 , V 21 

1 

SAVEVALUF 

V23,P3 

2, 

SAVEVALUE 

100, V21 

3 1 ■ 

savf.value 

V 2 3 , p 4 

j 

4 

SAVEVALUE 

100, V?1 

' 

c 

-t 

SAVEVALUE 

V20,«5 

6 

SAVEV ALUr 
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j 

7 

SAVEVALUE 

V20.P* 

3 

e 

savevaluf 
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9 

SAVEV ALUC 
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0 

SAVEVALUE 

100,  V?1 
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SAVEVALUE 
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j 

2 
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3 
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V20  »p9 

4 
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s 
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F 
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savevalue 
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: 1 « 
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LOOP 
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, ! i 
■1  • 
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LANO 
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TEST  LE 

P1,K100,TA BUL  PRINT  AS  EA  A/C  OF  FIRST  FLT  LANDS 

; 3 

POINT 

,,P 

PRINT  PARAMETERS  AS  CACM  A/C  LANPS 

u 

PRINT 

1,P0C,X 

OUTPUT  ALL  SAVEVALUES 

c TAPUL  TABULATE 

6 TABULATE 

7 TABULATE 

* TABULATE 

9 TABULATE 

c test  E 

1 SAVEVAUJF 

2 HER  SAVEVALUE 

3 TcSt  GE 

4 ASSIGN 

5 TABULATE 

f-  SAV^VftLUr 

7 SAVEVAL'JE 

f JUMP  TERMINATE 


°4,K1,0TH-R 
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42,  KO 
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UPO  A T F A/S  TABLE 
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UPOATF  G/3  TABLE 
UPOATE  FUEL  TABLE 
UPDATE  TRANSIT  TIME  TARLE 
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, JUMP  IF  X42  GE  MO,  IN  FL  T TAB  RECOV-PV  TIME 


TABULATE  RECOVERY  TIME 
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LOAO  PS  WITH  LOC  OP  SE R NO 
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TABLE  DEFINITIONS 

EACH  TABLE  IS  A FREQUENCY  DISTRIBUTION 
AIRSPEED  (SEC/MT) 

1 TABLE  07,10,1,30 

HEADING  ERROR 

2 TABLE  PB*-53*1.101 

GLIOESLOPF  ERono 

3 TABLE  P°  * -5  0 « 1 ♦ 10  1 

FUEL  REMAINING  (SEC) 

4 TARL-  P5, 0*10*30 

INDIVIDUAL  A/C  TRANSIT  TIME 

7 TABLr  Ml,  3600,100*100 

RECOVERY  TABLE 

5 TABLE  M*>12* 3000,330,90 


*«*«***+#** 


RUM  SIMULATION  FOR  THE  RECOVERY  OF  A NUMBER  OF  FLIGHTS  TO  COLLECT  AN 
ADEQUATE  SAMPLE  FOR  STATISTICAL  ANALYSIS. 
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